Models provide a technique for abstracting real world events, attributes, etc. The creation of these models typically involves domain specific challenges and issues. Metamodels provide a further abstraction of a model and may abstract the above domain specific challenges associated with models. A metamodel highlights or defines the properties of how the individual models are to be built. Many different modeling languages implement the above model and metamodel features through graphical user interfaces (GUIs) that allow disparate industries and areas of application to take advantage of optimization of business practices or software development.
The international standardization organization Object Management Group (OMG) defines a four level standard architecture. FIG. 1 shows the standard four tiers from the OMG-defined architecture. The subject of the model 108 is at tier M0, which is the object to be analyzed with a graphical model. This is also sometimes referred to as the data layer that may be used to describe real-world objects.
At tier M1 is the graphical model 106 of the regarded object on level M0. The model 106 may be expressed as an example model 114 (or a series of example models). The model may be represented in a modeling language such as the UML (Unified Modeling Language) or the like. Models at tier M1 are usually created in a clearly defined notation, rather than with arbitrary modeling elements and symbols. One reason for this is that the meaning of the defined model could be unclear on such an abstract level and thus may not be implementable (e.g., the model may be too domain specific).
Tier M2 generally defines the modeling elements and their relations. The definition of the syntax of the modeling language used in model 106 is called the metamodel 104. In addition to defining the elements used to create a model, metamodels are also used in order to specify the data structures that are needed to represent a model on any storage. At tier M2, the metamodel 104 may be expressed in a language. A common example is the UML metamodel, the model that describes UML.
At the highest level is tier M3, which includes the meta-metamodel 102. This defines the modeling language that is used in order to create a metamodel. As with the tier described above, meta-metamodels can be expressed in a language. OMG uses the “Meta Object Facility” (MOF) 110 standard for defining the specification of metamodels. This standard uses UML 2.0 class diagrams and the Object Constraint Language (OCL) in order to specify a metamodel.
Thus, a meta-metamodel language such as MOF 2.0 may in turn specify a metamodel language such as UML 2.0 and OCL. These languages in turn may be used to specify a particular model (e.g., the business practice of a company).
It will be appreciated that if the metamodel is defined such that it is compatible with industry standards, then it can be used for the generation of modeling tools, for the specification of storage formats, the documentation of modeling language, etc. Specifications are especially useful in the form of so-called domain specific languages (DSLs). These languages are usually not completely new but instead are typically derived from standard modeling languages and cover the special issues of a particular domain. DSLs may speed software development in a given domain because the needed modeling elements are provided in a more direct way.
Conventionally, tools that support and identify metamodels as assets do so though graphical metamodeling editors. The creation of these metamodels through such tools is a process in which a user manually creates a given metamodel.
One technique of automating the creation of metamodels involves providing other metamodels to create more metamodels or, in other words, converting one M2 tier model into another M2 tier model. Another conventional technique is the automatic creation of models out of metamodels. For example, UML models (e.g., at tier M1) may be created out of MOF metamodels. Accordingly some amount of automatic creation of models and/or metamodels has been achieved. However, those skilled in the art will appreciate that more work is still needed to reduce the manual task of model, metamodel, and/or meta-metamodel creation.
One aspect of certain example embodiments relates to the creation of metamodels in an automated process. In certain example embodiments, the automated process is a method implemented on a processing system.
Another aspect of certain example embodiments relates to providing a procedure from the creation of metamodels that is scalable and/or non NP-complete. In certain example embodiments, a large number of example models may be used in order to generate a metamodel.
Another aspect of certain example embodiments is the optimization of a generated metamodel. In certain example embodiments, the complexity of the metamodel is reduced during the optimization process. In certain example embodiments, abstract model elements are used that reduce the number of edges and/or nodes in a generated metamodel.
Still another aspect of certain example embodiments relates to the extension of existing modeling languages as well as their generation from scratch.
Still aspect of certain example embodiments relates to providing a graphical visualization that uses nodes, edges, and/or container nodes (e.g., nodes that enclose nodes, edges, and other container nodes).
Yet another aspect of certain example embodiments relates to generating a metamodel that follows OMG standards MOF, which may be based on the UML 2.0 class diagram and OCL standards.
Yet another aspect of certain example embodiments relates to allowing users with little or no technical background to use and/or produce the generated metamodels.
In certain example embodiments, a method of creating a metamodel for use with a processing system including at least one processor is provided. Nodes, edges, and multiplicities are automatically identified from at least one example model. A preliminary metamodel is created by (a) adding to the preliminary metamodel a corresponding metaclass node for each said automatically identified node in the at least one model and a corresponding metaclass edge for each said automatically identified edge in the at least one model, and (b) connecting each said added metaclass edge to at least two said added metaclass nodes via first and second associations, with the first and second associations having opposite directions and having respective multiplicities associated therewith. Detection as to whether multiple relationships exist is performed by determining whether any of said added metaclass edges are connected to more than two added metaclass nodes. The preliminary metamodel is refined when it is determined that at least one multiple relationship exists so as to create a refined metamodel, but otherwise the preliminary metamodel is treated as the refined metamodel.
In certain example embodiments, a metamodel creation system is provided with at least one processor, display, and user input adapter for receiving user input. The system may be configured to automatically identify nodes, edges, and multiplicities of at least one example model. The system may be further configured to create a preliminary metamodel by adding metaclass nodes to the preliminary metamodel for each said automatically identified node in the at least one model and a corresponding metaclass edge for each said automatically identified edge in the at least one model. The system may also be further configure to connect each said added metaclass edge to at least two said added metaclass nodes via first and second associations, the first and second associations having opposite directions and having respective multiplicities associated therewith. The system may be configured to detect whether multiple relationships exist by determining whether any of said added metaclass edges are connected to more than two added metaclass nodes. The system may also be configured to refine the preliminary metamodel when at least one multiple relationship exists so as to create a refined metamodel, but otherwise treating the preliminary metamodel as the refined metamodel.
There also are provided in certain example embodiments non-transitory computer readable storage mediums tangibly storing instructions that, when processed by at least one processor, execute the above-described and/or other methods.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments.